Oci8 problem on 64-bit bigendian platforms, bug#73002 #7424
Conversation
trivially converted into pointers to 4-bytes field. Explained in details here: https://bugs.php.net/bug.php?id=73002
|
Thank you for the PR! As I understand it, this is a real bug fix, and as such might better target PHP-7.4 or PHP-8.0. And having a test case which shows the erroneous behavior would be welcome (even if the test would not fail on CI, or even not executed there). Anyhow, @cjbj, could you have a look at this PR? |
unnamed PL/SQL-block, assign value to bind-variable (string type)
| #define ZendLongPtr2OciPhpsizedIntPtr(zendlongptr) \ | ||
| ((oci_phpsized_int *)((char *)(zendlongptr)+(sizeof(zend_long)-sizeof(oci_phpsized_int)))) | ||
| #endif | ||
|
|
There was a problem hiding this comment.
IMHO this does not looks like a proper fix
Moving the pointer is not the proper way when size differ, especially as other bytes are not initialized
Should use a temp storage of the proper size.
There was a problem hiding this comment.
Indeed, using uint64_t * (or ub8 * in Oracle terms) pointers instead of uint32_t * (or ub4 *) pointers is not correct. This problematic behaviour wasn't created by my patch, it already existed; the patch only made it visible, as in big-endian platform it is different:
little-endian: ub4* shortintptr= (ub4 *)&ub8variable;
big-endian: ub4* shortintptr= (ub4 *)((char *)&ub8variable+4);
Refactoring the code using temporary variables would be possible (they should put into struct php_oci_bind), but would require quite a bit of work (cf https://bugs.php.net/bug.php?id=73002#1473330938 )
|
Hi @cmb69 |
|
Thank you guys for all your efforts. Best wishes. |
4 participants
On 64-bit big-endian platforms pointers to 8-bytes field cannot be
trivially converted into pointers to 4-bytes field.
Explained in details here: https://bugs.php.net/bug.php?id=73002
This affects strings' length-fields, booleans, and integer values for Oracle client 10 (and older).